Automatic signature propagation network

ABSTRACT

A distributed security system wherein intelligent security agents (i.e., agent devices) share security incident information between themselves via a controller. An adaptive security decision making involving network worms (non-SMTP worms) and DoS floods attacks is also described; wherein the Worms and DoS flood digital signatures are generated to assist in intrusion prevention process.

RELATED APPLICATIONS

This application claims the benefit of U.S. Provisional Application 60/828,691 filed Oct. 9, 2006, which is incorporated herein by reference.

BACKGROUND OF THE INVENTION

1. Field of Invention

The present invention relates generally to the field of intrusion prevention. More specifically, the present invention is related to a novel self-optimizing intrusion prevention system and method.

2. Discussion of Prior Art

FIG. 1 illustrates a prior art intrusion prevention process 100. In such a prior art process, known attack patterns are filtered through the Attack Signature Filtering engine 102 (supported by a vulnerability research team) and the rest of the traffic is passed through a Behavior Analysis component 104. Behavior Analysis component 104 is responsible for detecting abnormal activities that were not detected by the signature engine (such as new and unknown attacks), and to characterize and mitigate them according to this characterization.

In this scenario, the word ‘mitigate’ is key, as prior art Behavioral Analysis technologies cannot hermetically block unknown attacks, but rather mitigate them. This inherent limitation of the prior art originates in the fact that a Behavior Analysis system must analyze multiple sequential events before making an accurate decision about a behavior. Thus, there is always a chance that the attack will be able to slip through and hit the protected network. Taking the example of worm propagation, even a small amount of packets that succeed to slip through the protection before the behavior of the worm has been correctly characterized can impose a threat to the network.

The U.S. patent to Anderson et al. (U.S. Pat. No. 7,028,179), assigned to Intel Corporation, teaches an apparatus and method for secure, automated response to distributed denial of service attacks. Anderson et al. teach a method comprising the steps of receiving notification of a distributed denial of service (DDoS) attack, establishing security authentication with an upstream router from which attack traffic is received, and transmitting one or more filters to the upstream router such that attack traffic is dropped by the upstream router to terminate the DDoS attack. However, it should be noted that Anderson et al.'s method fails to teach or suggest a signature characterization process and/or propagation rules mechanisms implemented in conjunction with such transmission of filters.

Whatever the precise merits, features, and advantages of the prior art, none of them achieves or fulfills the purposes of the present invention.

SUMMARY OF THE INVENTION

Embodiments herein describe a distributed security system based on intelligent security agents that share security incident information between them. The system provides adaptive security decision making involving network worms (non-SMTP worms) and DoS floods attacks. The present invention provides an adaptive process that reduces blocking response time and improves protection coverage against unknown (“zero-day”) attacks, such as (but not limited to) worms and DoS/DDoS flood attacks. Embodiments herein automatically create, characterize and then propagate (based on the characterization attributes), worms and DoS flood digital signatures which assist in the intrusion prevention process, which may be as a complementary solution to the traditional attack signatures detection method. Thus overall security coverage of each individual network security device when under attack is improved. In addition, an in-depth risk analysis—analysis of major attack outbreaks and their propagation vectors per and between geographical areas may be provided.

Embodiments herein describe a distributed security system comprising a plurality of intelligent security agents distributed across a network, the intelligent security agents include a black list identifying a plurality of signatures used in restricting packet flow in the network; a signature creating module to create an attack signature through behavioral analysis; a propagation mechanism to propagate the created attack signature to a controller; an external update mechanism to receive updates to the black list from the controller; and the controller communicating with the plurality of the intelligent security agents over the network, the controller receiving the created attack signatures from at least one intelligent security agent and, according to pre-defined propagation rules and the signature's characteristic attributes, the controller updating a black list associated with the plurality of intelligent security agents distributed across the network with the created signature.

Also described is an article of manufacture comprising a computer usable medium having computer readable program code embodied therein. The computer readable program code for maintaining a black list identifying a plurality of signatures used in restricting packet flow in the network; for creating an attack signature and a signature's characteristic attributes through behavioral analysis; for aiding in propagating the created attack signature to a controller; for aiding in receiving updates to the black list from the controller. Additionally the controller communicates with the plurality of intelligent security agents over the network, the controller receiving created attack signatures from at least one intelligent security agent and updating (for example, through pre-defined propagation rules that are based on the signature's characteristic attributes) a black list associated with each of the plurality of intelligent security agents distributed across the network with the created signature.

Another embodiment describes a plurality of intelligent security agents distributed across a network, and a method as implemented in the intelligent security agents includes identifying a plurality of signatures used in restricting packet flow in the network; creating an attack signature through behavioral analysis based on attack footprint information; propagating the attack signature to a controller. The controller may receive the attack signature from an intelligent security agent, and the controller, according to a pre-defined propagation rules and the signature's characteristic attributes, updating a black list associated with the plurality of intelligent security agents distributed across the network with the attack signature. The update being performed via an external update mechanism associated with the plurality of intelligent security agents distributed across the network. The footprint information may relate to DoS attacks and worm attacks.

In addition, a method implemented in a controller communicating with a plurality of intelligent security agents distributed across a network is described. The method includes: receiving at least one attack signature from an intelligent security agent over the network, the attack signature created through behavioral analysis based on attack footprint information regarding DoS attacks and worm attacks; propagating the received attack signature to the plurality of intelligent security agents (based on the pre-defined propagation rules and the signature's characteristic attributes), wherein a black list associated with the plurality of intelligent security agents distributed across the network is updated with the propagated attack signature.

Also described is an article of manufacture comprising a computer usable medium having computer readable program code embodied therein, the medium comprising: computer readable program code for identifying a plurality of signatures used in restricting packet flow in the network; for creating an attack signature through behavioral analysis based on attack footprint information; for aiding in propagating the attack signature to a controller; wherein the controller receives the created attack signature from an intelligent security agent and the controller updating a black list associated with each of the plurality of intelligent security agents distributed across the network with the attack signature (based on the pre-defined propagation rules and signature's characteristic attributes).

Another embodiment describes an article of manufacture comprising a computer usable medium having computer readable program code embodied therein for execution by a controller comprising: computer readable program code for aiding in receiving at least one attack signature from an intelligent security agent over the network, the attack signature created through behavioral analysis based on attack footprint information regarding DoS attacks and worm attacks; for aiding in propagating the received attack signature to the plurality of intelligent security agents (based on the pre-defined propagation rules and the signature's characteristic attributes), wherein a black list associated with each of the plurality of intelligent security agents distributed across the network is updated with the propagated signature.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 illustrates an intrusion prevention process.

FIG. 2 illustrates an exemplary embodiment of an intrusion prevention process.

FIG. 3 illustrates an exemplary embodiment of a Signature Propagation Concept.

FIG. 4 illustrates a system diagram describing modules associated with the present invention.

FIG. 5 illustrates a process occurring prior to the creation of a generic signature by the Behavioral Denial of Service (B-DoS) module.

FIG. 6 illustrates a flow chart outlining how a DoS signature accuracy score is calculated.

FIG. 7 illustrates a negative weight function (relevant for packet size footprint type) that maps the number of different packet size values that are included in the attack footprint to a worm characteristic score (score range between 1 and 5).

FIG. 8 describes a positive weight function that maps the number of different footprint type values that are included in the attack footprint into a worm characteristic score.

FIG. 9 illustrates a flow summarizing footprint rule characterization processes.

FIG. 10 illustrates a process occurring prior to the creation of a generic signature by the Anti-scan module

FIG. 11 illustrates how the network scan signature accuracy score is calculated.

FIG. 12 illustrates an anti-scan worm characterization process.

FIG. 13 summarizes the above-mentioned anti-scan footprint rule characterization process.

FIG. 14 illustrates a signature propagation flow.

FIG. 15 illustrates a timing diagram outlining a typical agent device-controller message exchange.

FIG. 16 illustrates a timing diagram outlining the Controller's message exchange.

FIG. 17 illustrates generic signature “blocking” states and transition rules, wherein the signatures states are controlled by the controller.

FIG. 18 illustrates generic signature trace states and the transition rules, wherein the signature states are controlled by the controller.

FIG. 19 illustrates a timing diagram showing the registration process between an agent device and a controller.

FIG. 20 illustrates a timing diagram showing the interaction between the primary and secondary controllers.

FIG. 21 illustrates a timing diagram showing an agent device and secondary controller recovery.

FIG. 22 illustrates a horizontal signature propagation scenario (carrier environment).

FIG. 23 illustrates the vertical signature propagation scenario (carrier environment).

FIG. 24 illustrates vertical and horizontal propagation scenario (carrier environment).

FIG. 25 illustrates typical trace propagation scenarios (carrier environment).

DESCRIPTION OF THE PREFERRED EMBODIMENTS

While this invention is illustrated and described in various embodiments, the present disclosure is to be considered as an exemplification of the principles of the invention and the associated functional specifications for its construction and is not intended to limit the invention to the embodiments illustrated. Those skilled in the art will envision many other possible variations within the scope of the present invention.

The intrusion prevention process is capable of optimizing itself in a manner that minimizes the chances that zero day DoS and Worm attacks will slip through the protection system. The intrusion prevention process characterizes the signature of a created “behavioral” signature (through attributes of accuracy, generality etc) and uses these characteristics for efficient signature propagation between devices in different network locations (and across networks).

FIG. 2 illustrates an exemplary embodiment of an intrusion prevention process 200.

Automatic Attack Signature Creation—202

As shown in FIG. 2, the intrusion prevention process 200 includes an automatic creation of DoS floods and Worms attack signatures through behavioral analysis. Examples of two technologies to create the attack signatures are listed below:

1. Behavioral DoS protection; and

2. Enhanced anti-scan protection that enables an accurate characterization of the packets participating in the scan (i.e., scan's footprint), wherein the anti-scan will enable more specific characterization of self-propagating network worms (including low-rate propagation that typifies the initial worm infection activities in a network).

In one embodiment, the automatic attack signatures are defined according to parameters that are taken from the headers of layer 3, layer 4 and a few parameters that are taken from layers 5 and 7.

Automatic Signature Propagation

Upon creation of an attack signature, the system will send the signature to the controller. The next step is to propagate the signatures to the other agent devices (to a generic black list in each agent device) according to a pre-defined propagation rules. Any packet that matches the signature will be dropped (the agent device that created the attack signature can get the generic signature back if the signature propagation rules in the controller will instruct to do so).

FIG. 3 illustrates a Signature Propagation Concept. FIG. 3 illustrates a signature propagation network that includes three agent devices. When the first agent device detects (through statistical behavioral analysis) a zero day network worm, the worm is characterized and a worm signature is created accordingly. The worm signature is then propagated to the other agent devices. It should be noted that with respect to the description of FIG. 3, the controller (not shown) is responsible for the signature propagation between agent devices. The other devices can then block this worm immediately according to the signature. The following describes the mechanism that is responsible for the signature creation.

FIG. 4 illustrates a system diagram describing modules associated with the present invention. B-DoS 402 and Anti-scan modules 404, configured to be part of the generic signature generation process, send attack footprint information to the generic signature creation modules 406. The generic signature creation modules 406 are responsible for selecting footprint types and values that are “appropriate” to be included in a generic signature according to pre-defined rules. A decision is made according to multiple signature characteristics parameters such as footprint type, footprint accuracy/strictness level, footprint consistency, attack duration and other parameters that are analyzed before a generic signature can be created. Some of these parameters can be tuned through advanced configuration options (for example, in each agent device).

Upon generation of a new generic signature, the system, using propagation mechanism 407, sends the new generic signature to the “controller” 408 (i.e., controller) over a network 409 (e.g., the Internet). Controller 408 is responsible for all signature propagation tasks. Controller 408 updates the external agent device's black list 410 using external update mechanism 411. When agent device receives a new generic signature list from the controller 408, it updates the Generic Signatures Black List 410 with it. The generic black list 410 improves the response time of the system itself to new zero-day attacks.

In one embodiment, the black list is configured to apply only to certain policies through advanced configuration, i.e., the admin can select a network segment that will not be protected by the generic signatures.

By allowing policy based signature propagation, MSSP (Managed Security Service Provider) that protects multiple customers through multiple policies in one box will be able to give this service only to the customers that have paid to be part of the automatic signature propagation network.

According to the configured policy, a packet that enters the system will be inspected by the generic black list, and in case a match is found, the packet will be dropped before forwarding it to other protection modules in the system.

Generic Signature Creation

Each generic signature generation module 406 receives inputs from the protection module. In this stage, there are two protection modules: B-DoS protection 402 and Anti-Scan module 404 (it is also envisioned that more protections that can generate attack behavioral signatures can take advantage of this generic signature creation module and the automatic signature propagation system). The generic signature creation module 406 analyzes each detected attack footprint rule (the footprint rule is composed from multiple footprint types and values) and decides if to approve, modify or reject it according to generic rules criteria.

Generic Rules Criteria (B-DoS)

Upon detection of an attack, the B-DoS module generates an attack footprint rule consisting of attack footprints types and values. Tables 1-4 lists examples of footprint types that can be included in the attack footprint rule. Each footprint type is characterized according to the level of its generality, accuracy and a worm characteristic score.

TABLE 1 All TCP Behavioral Flood Protections - Footprint Types Table Footprint Generic/ Generic/ type Default worm Default Footprint source target Accuracy characteristic configuration H# Type Generic area area level score mode 1 TCP Yes — — High Zero Enabled Sequence Number 2 IP ID number Yes — — High Zero Enabled 3 Source Port No — — Med Low Dynamic 4 Source IP No Yes No Low Zero Dynamic address 5 ToS (Type of Yes — — Med Med Enabled Service) 6 Packet Size Yes — — Med Low Enabled 7 Fragment Yes — — Low — Disabled 8 Fragment Yes — — High — Enabled offset 9 Destination Yes — — Low dynamic score Enabled Port (High-Low, Negative) 10 Destination IP No No Yes Low dynamic score Disabled address (Zero-High, Positive) 11 TTL No¹ Yes Yes Med — Disabled ¹Generic for a specific route between source and target networks

TABLE 2 All UDP Behavioral Flood Protections - Footprint Types Table Footprint Default Generic/ Generic/ Type worm Default Footprint source target Accuracy characteristic configurable H# Type Generic area area level score mode 1 Transport No No No High Zero Disabled Checksum 2 IP ID Yes — — High Zero Enabled 3 DNS ID Yes — — High — Enabled number (port 53) 4 DNS Qname No No Yes Low — Disabled (port 53) 5 DNS Qcount Yes — — High — Enabled (port 53) 6 Source Port No No No Med Low Dynamic 7 Source IP No Yes No Low Zero Dynamic address 8 ToS (Type of Yes — — Med Med Enabled Service) 9 Packet Size Yes — — Med Dynamic Enabled score (High-Low, Negative) 10 Destination Yes — — Low Dynamic Enabled Port score (High- Low, Negative) 11 Destination IP No No Yes Low dynamic Disabled address score (Zero-High, Positive) 12 Fragment Yes — — Low — Enabled 13 TTL No¹ Yes Yes Med — Disabled

TABLE 3 All ICMP Behavioral Flood Protections - Footprint Types Table Generic/ Generic/ Default worm Default Footprint source target Accuracy characteristic configuration H# Type Generic area area level score mode 1 Transport No — — High Zero Disabled Checksum 2 IP ID number Yes — — High Zero Enabled 3 Source IP No Yes No Low Zero Dynamic address 4 ToS (Type of Yes — — Med Med Enabled Service) 5 Packet Size Yes — — Med Dynamic Enabled score (High-Low, Negative) 6 Destination IP No No Yes Low dynamic score Disabled address (Zero-High, Positive) 7 ICMP Yes — — Low Low Enabled Message Type 8 Fragment Yes — — Low — Enabled 9 TTL No¹ Yes Yes Med — Disabled

TABLE 4 All IGMP Behavioral Flood Protection - Footprint Types Table Generic/ Generic/ Default worm Default Footprint source target Accuracy characteristic configuration H# Type Generic area area level score mode 1 Transport No — — High Low* Disabled Checksum 2 IP ID number Yes — — High Low* Enabled 3 Source IP No Yes No Low Low* Dynamic address 4 ToS (Type of Yes — — Med Low* Enabled Service) 5 Packet Size Yes — — Med Low* Enabled 6 Destination IP No No Yes Low Low* Disabled address 7 IGMP Yes — — Low Low* Enabled Message Type 8 Fragment Yes — — Low — Enabled 9 TTL No¹ Yes Yes Med — Disabled ¹Generic for a specific route between source and target networks *Note: IGMP will probably not be used as a transmission protocol for worm propagation; therefore, all worm scores are set to low.

B-DoS (Behavioral Denial of Service) Generic Signature Decision Making

FIG. 5 illustrates a process that takes place in each generic signature creation module before B-DoS generic attack signature is created.

Blocking Rule Consistency Check—502

In case that the BDoS controller (the controller is a finite state machine that holds that BDoS protection states) remains more than CTh seconds in state 6 (i.e., blocking state), the attack footprint rule is considered to be effective and stable. Any other controller state represents an attack footprint rule that is in the middle of creation or an optimization process or not strict enough (e.g., too many OR's and not enough AND's logical relationships).

Short periods in state 6 also represents a dynamic characteristics of the detected attack, therefore the attack footprint rule will not be a candidate for a generic automatic signature.

Any transition to state 6 will reset the CTh timer again.

Local Strictness Level Conditions—504

A DoS/DDoS Attack footprint rule strictness level is determined according to the number of OR's and AND's logical expressions that construct the rule. Two thresholds: ORTh and ANDTh define the required strictness. These thresholds are configurable inside a set of four strictness profiles.

In case that the footprint rule includes only “high accuracy” footprint types, then the strictness conditions are by-passed and the accuracy level is set automatically to 5 (i.e., very high).

Attack Footprint Rule Refinements and Characterization—506

Footprint Rule Refinements:

-   -   a. After the initial two checks, the system will check if there         are pre-defined disabled footprint types inside the footprint         rule and will remove them. Disabled footprint types are         specified in Tables 1-4 above.         -   After removing these footprint types, the footprint rule             strictness level is measured again against the refined             signature.     -   b. If after removing the disabled footprints the strictness         level remains in the defined constraints, the system will try to         remove (in a pre-defined order) the “dynamic” footprints type in         order to generalize the footprint rule. Removing dynamic         footprints will occur only if the resultant footprint rule         strictness level still complies with the ANDTh constraints (in         this way the system will try to achieve the most generic         signature that also comply with the pre-defined strictness         rules). Dynamic footprint types are specified in Tables 1-4         above.

Footprint Rule Characterization Process:

Accuracy score—The new DoS/DDoS footprint rule is assigned with an accuracy score. This score is defined according to the number of AND's, OR's logical relationships (i.e., footprint's strictness level) and the accuracy level of the existing footprint types. This score enables the propagated generic signature to be identified with a level of accuracy before it is allowed to update the generic signature black lists(s) on other agent devices through the controller.

FIG. 6 illustrates a flow chart outlining how such an accuracy score is calculated. High accuracy footprints types are specified in Tables 1-4 above (e.g., TCP sequence number, L4 checksum etc).

a. The system checks (601) to see if the footprint rule includes only “high accuracy footprint types” (602), then the footprint accuracy score is set to 5 (Very high) (604). If not (606), then,

b. The system checks the lowest strictness level that is associated with the footprint rule. There are four pre defined strictness levels (i=1, 2, . . . , 4. Level 4 is the highest level).

c. In case i<4, then the system assign accuracy level according to (i) between 1 and 3 (i.e., Very low to Medium) (608).

d. In case i=4, then the system checks if the footprint rule includes at least one “high accuracy footprint type.” If it is, then the system sets i to 5, i.e., Very high accuracy level. If not, then the footprint's rule accuracy level is 4 (High) (610).

Generality flag—Together with the accuracy score, the footprint rule is assigned with a flag that represents the level of its generality. There are three generality types:

-   -   1. Generic (g)—Totally generic rule. This means that the         DoS/DDoS attack footprint can be effective for all networks.     -   2. Generic/source (s)—The generality of the DoS/DDoS footprint         rule is limited to a source network (the generic signature         includes a source IP address(es)). This signature is effective         only in blocking attack traffic that originates in the same         source IP address as specified by the agent device that created         the attack footprint rule (i.e., same attack from other sources         will not be blocked). This option can fit the requirements of         large internal networks.     -   3. Generic/target (t)—The generality of the DoS/DDoS footprint         rule is limited to a target network (i.e., the generic signature         includes destination IP address(es)). This means that the attack         footprint is relevant only for certain networks such as:         -   a) Multiple devices that protect a few internet links of the             same network;         -   b) Multiple devices located in the internal network, in the             internet gateway of the same network and/or in the upstream             (e.g., ISP) that provides the Internet services to the same             network (i.e., all protect the same network IP range).     -   4. Both (b)—The generality of the rule is limited to a         combination of certain target and origin networks.

Worm Characteristic Level

The DoS/DDoS footprint rule is assigned with a worm characteristic level according to the existing footprint types.

-   -   1. High—high probability that the DoS/DDoS footprint rule         represents worm propagation activities     -   2. Med—Medium probability that the DoS/DDoS footprint rule         represents worm propagation activities     -   3. Low—The footprint rule represents DoS/DDoS attack which is         probably not the result of worm propagation activities.

It should be noted that this characteristic level, even if it is set high, doesn't insure that the detected attack contains worm propagation but rather identifies the odds. It is more likely that when the characteristic is set low then one can be sure that the detected flood isn't associated with worm activities.

The Following Worm Characteristic Mechanism is Needed:

The worm scoring mechanism works per L4 flood attack (i.e., TCP syn, TCP others, UDP flood, ICMP flood and IGMP flood).

The worm level is calculated according to the pre-defined footprint score (worm characteristic score—High, Med, Low or Zero) and, in some cases, the number of footprint values that were detected per each of these footprint types (may be termed the ‘dynamic score’ case).

Worm Dynamic Score

Some of the attack footprint types such as source IP, Destination port, packet size etc, need to have a dynamic worm score mechanism. The score starts at a pre-defined value (as defined in Tables 1-4 above in the default worm characteristic score column) and is changed according to a score weight function. The weight function's input is the type of footprint (e.g., destination IP, Packet size, etc) and the number of detected footprint values of the same footprint type.

There are two types of weight functions: positive and negative:

FIG. 7 illustrates a negative weight function (relevant for, but not limited to, packet size footprint type) that maps the number of different packet size values that are included in the attack footprint to a worm characteristic score (score range between 1 and 5).

FIG. 8 describes a positive weight function that maps the number of different footprint type values that are included in the attack footprint into a worm characteristic score.

It should be noted that:

-   -   Currently, the destination IP footprint type will use the         positive weight function     -   Tables 1-4 above specifies which footprint type will use the         weight function (i.e., will have dynamic worm characteristic         score).     -   Specification of the weight function is specified below

Worm Static & Dynamic Scores—Specification of Weight Functions

There are two types of worm characteristic scores:

-   -   Static score—This is a static score meaning that it doesn't         depend on any other Footprint properties. The following Static         Score Types are used (for each footprint, that was defined as         non-dynamic score in Tables 1-4):

TABLE 5B Static Score Type Numeric values ZERO 0 LOW 1 MEDIUM 3 HIGH 5

-   -   Dynamic Score—The value of this kind of attribute is a pair of         Dynamic Score Type (DST) and integer number (num) higher than         zero that represents another property of the footprint.         -   The value of ‘num’ can be for example the number of             footprint values that were detected per each of these             footprint types (e.g., number of different packet size             values, number of different destination IP addresses etc).         -   Typical Dynamic Score Type (DST) that are used are:             -   1. ZERO-HIGH (positive)             -   2. HIGH-ZERO (negative)             -   3. LOW-HIGH (positive)             -   4. MEDIUM-HIGH (positive)             -   5. MEDIUM-ZERO (negative)     -   DST parameter defines the behavior of the weight function and         the num value (number of different footprint value) is the         function's input.

Weight Function w( )

A typical weight function is cubic spline with only one internal bound point (xinflection) and boundary conditions (xmin, xmax). Each such type of function is uniquely described through a set of 5 values:

-   -   xmin, xmax specifies the interval where function varies (the         weight outside this interval is defined as constant);     -   ymin is min weight value;     -   ymax is max weight value;     -   xinflection is x-position of inflection point; and     -   direction: UP/Down

FIG. 8 illustrates weights associated with specific characteristic parameters. Table 5C, below, specifies the default weight function characteristics parameters.

TABLE 5C DST Xmin Xmax Ymin ymax xinflection Direction Zero-High 3 29 0 5 20 Up (Positive) High-Zero 3 29 0 5 12 Down (Negative) Low-High 3 29 1 5 20 Up (Positive) High-Low 3 29 1 5 12 Down (Negative) Medium- 3 29 3 5 20 Up High (Positive) Medium- 3 29 0 3 12 Down Zero (Negative)

Total Worm Characteristics Score

After setting a worm score (static or dynamic) for each footprint type, the final (total) worm characteristic score is calculated according to the following weight function:

${s = {\exp\left( \frac{{l\;{H \cdot N_{H}}} + {l\;{M \cdot N_{M}}} + {l\;{L \cdot N_{L}}} + {\sum\limits_{i = 1}^{K}\;{{lan}\left( W_{i} \right)}}}{N_{H} + N_{M} + N_{L} + K} \right)}},$ where:

-   1H=lan(5), IM=lan(3), IL=lan(1)=0 -   N_(H) is a number of high score footprint types -   N_(M) is a number of medium score footprint types -   N_(L) is a number of low score footprint types -   K is a number of weighted scores (i.e., number of footprints that     went through weight function) -   W_(i)=Weighted score of footprint.

Table 5A, below, defines how the final worm's score/level is set:

TABLE 5A Worm weighted score range Final worm level worm_score ≧ 4 High 3 ≧ worm_score < 4 Med worm_score < 3 Low Notes:

-   -   The default worm score weight function footprint type and L4         protocol are specified in the Tables 1-4 above in the default         worm characteristic score column.     -   A geometric type of average is used in the formula in order to         increase the influence of small values on the result.     -   In case zero score footprint exist, the total worm score (s) is         set to zero.

Attack rate—The new generic DoS/DDoS signature rule is assigned with a traffic rate parameter. The rate includes both PPS and Bytes/sec statistics. The rate is calculated through the Behavioral DoS module. This parameter represents the attack intensity which is associated with the generic DoS/DDoS signature.

Attack direction—When possible, an attack direction flag will be assigned to each DoS and DDoS generic signature rule.

FIG. 9 illustrates a flow that summarizes all footprint rule characterization processes. It should be noted that Attack system time will be assigned to each DoS/DDoS generic signature rule.

Generic Signature Criteria (Anti-Scan)

Most self-propagating network worms (non-SMTP worms) scan the network in order to find vulnerable hosts, thus these activities can be detected by an anti-scan module. The anti scan module is responsible for characterizing the pattern of scan and mitigating it accordingly.

Upon detection of an attack, the Anti-scan module generates a scan attack footprint rule consisting of scan footprint types. A worms' propagation patterns usually include certain footprint types that will be recognized by the anti-scan generic signature creation module.

It should be noted that it is unavoidable that certain pure scanning activities (pre-attack probe activities) will be characterized as worm propagation. However, there is also a benefit in the detection of generic signatures that identifies new automatic network scanning tools (i.e., pre-attack probe tools) and blocking them through an automatic signature propagation network.

The anti-scan raises an attack alert per L4 protocol type (TCP, UDP or ICMP). Tables 6-8 outline footprint types that can be included per protocol type (each footprint type is characterized according to the level of its generality, accuracy and worm level). It should be noted that in the case of the Anti-Scan generic signatures, the worm level is calculated through static score type.

TABLE 6 UDP Scans - Footprint Types Table Generic/ Generic/ Default worm Default Footprint source target Accuracy characteristic configuration # Type Generic area area level score mode 1 IP ID Yes — — High Zero Dynamic 2 Source IP No Yes** No Low — Dynamic address 3 Packet Size Yes — — Med High Enabled 4 Destination Yes — — Low High Enabled Port 5 Destination No No Yes Low Zero Disabled IP address 6 TTL No Yes Yes Med — Enabled 7 Payload hash Yes — — High High Enabled

TABLE 7 TCP Scans - Footprint Types Table Generic/ Generic/ Default worm Default Footprint source target Accuracy characteristic configuration # Type Generic area area level score mode 1 TCP Yes — — High Zero Dynamic Sequence Number 2 IP ID Yes — — High Zero Dynamic 3 Source IP No Yes** No Low — Dynamic address 4 Packet Size Yes — — Med —* Enabled 5 Destination Yes — — Low High Enabled Port 6 Destination No No Yes Low Zero Disabled IP address 7 TTL No Yes Yes Med — Enabled 8 HTTP URL Yes — — Low High*** Enabled 9 Payload Yes — — High High*** Enabled hash *In case of TCP, packet size cannot typically characterize worm activities (for this case a TCP stream/transaction size can be measured). **In internal networks configuration, source IP can be a good footprint in order to isolate hosts that are infected with worms. ***There is an option to use “delayed binding” (i.e., proxy) mechanism, as a dynamic “virtual honey-pot.” For example, when the anti-scan trigger and alerts, the protection system will respond by itself to the source of the scan (become a proxy) and thus will enable to identify payload footprints types inside the TCP transactions such as HTTP URL's, payload hash etc.

Another option that will allow the anti-scan protection module to identify a payload footprint inside the TCP transactions is to work in detection only mode. In this mode, when a TCP scan alert is generated, all packets that are associated with the source of the scan will be sent to a deep packet inspection (DPI) module in order to detect application level (L7) footprints. Only then will the filter become active.

TABLE 8 ICMP Scans - Footprint Types Table Generic/ Generic/ Default worm Default Footprint source target Accuracy characteristic configuration H# Type Generic area area level score mode 1 IP ID Yes — — High Zero Dynamic 2 Source IP No Yes** No Low — Dynamic address 3 Packet Size Yes — — High**** Low Enabled 4 ICMP Yes — — Low — Enabled Message type 5 TTL No Yes Yes Med — Enabled ****ICMP packet size can improve the accuracy of the footprint rule only in case that the detected size is not one of the default legitimate ICMP message sizes (e.g., 74 bytes).

FIG. 10 illustrates the generic signature decision making process 1000. The process takes place in each generic signature creation module before a generic automatic worm signature can be created.

Attack Footprint Rule Consistency and Scan Intensity Check—1002

A check 1008 is performed to see if the attack duration (scanning activities) is more than DTh seconds, and if so, the blocking rule is considered effective and stable (same as the attack activities). Next, check 1010 is performed to see if the attack footprint rule isn't a collective rule, which means that it includes more than just source IP address and L4 protocol footprint types, and if so, then the system goes to the next check. The next check 1012 is the average frequency of the attack. The frequency represents the intensity of the scanning activities which is supposed to be high (per source IP) in case of worm propagation (a worm that infects a host will try to use most of the hosts CPU resources in order to spread and infect other hosts). In case that the average attack frequency is above FTh [Hz], then the system continues to the next check. In one embodiment, these thresholds (DTh and FTh) are tunable through advanced configurations.

Local Strictness Level Condition—1004

Attack (scan) footprint rule strictness level is determined according to the number of AND's logical relationships that construct the rule. The threshold ANDTh defines the required strictness. This thresholds is configurable inside a set of three strictness profiles. In case that the footprint rule includes only “high accuracy” footprint types, then all other strictness conditions are by-passed and the accuracy level is set to 4 (i.e., very high).

Footprint Rule Refining and Characterization—1006

Footprint refinements:

-   -   a. After the initial four checks, the system performs check 1014         to see if there are pre-defined “disabled” footprint types         inside the attack footprint rule and if such “disabled”         footprints exist, then the system removes them in step 1016.         Disabled footprint types (those that, through configuration, are         not allowed to participate in the scan footprint rule) are         specified above in Tables 6-8. After removing these footprint         types, the footprint rule strictness level is measured again.     -   b. If after removing the disabled footprint the strictness level         remains in the defined constraints, the system, in step 1018,         removes the “dynamic” footprints type in order to generalize the         footprint even further. Removing dynamic footprints occur only         if the resultant footprint rule strictness level still complies,         as in step 1017, with the ANDTh constraints. Enabled, Dynamic         and Disabled footprint types are specified in Tables 6-8 above.

Footprint Rule Characterization Process

Accuracy score—The new footprint rule is assigned with an accuracy score. This score is defined according to the number of AND's logical relationships and the accuracy level of the footprint types that are included in the footprint rule. This score enables to be identify the signature with a level of accuracy before it is allowed to be propagated to other Agent devices (i.e., propagation rules that are implemented in the controller include accuracy conditions).

FIG. 11 illustrates how the accuracy score is calculated. High accuracy footprints types are specified in Tables 6-8 (e.g., TCP sequence number, IP identification number etc). The flow of FIG. 11 is presented below:

a. The system in step 1102 checks if the footprint rule includes only “high accuracy footprint types,” and if so, the footprint accuracy score is set to 4 (Very high) 1104. If not, then,

b. The system checks the lowest strictness level that is associated with the footprint rule. There are three pre-defined strictness levels (i=1, 2 or 3). Level 3 is the highest strictness level).

c. In case i<3, the system, in step 1106, assigns accuracy level according to (i), i.e., Very low or Medium

d. In case i=3, then the system checks, in step 1108, if the footprint rule includes at least one “high accuracy footprint type.” If it does include at least one “high accuracy footprint type,” then the system, in step 1109, sets (i) to 4, i.e., Very high accuracy level. If it does not include at least one “high accuracy footprint type,” then the footprint's rule accuracy level is set, in step 1110, to 3. i.e., High. Strictness profiles will be set as shown below in Table 9:

TABLE 9 i Strictness profile Minimum AND's Comment 1 Low 1 2 Med 2 3 High 3 4 Very High 3 With only high accuracy footprint types

It should be noted that:

-   -   1. Worm (scan) footprint rules can include OR logical         relationships between destination IP and Ports numbers. The         number of OR's are ignored in the process of accuracy         characterization (i.e., strictness level doesn't include OR         limitations).     -   2. Strictness profiles don't count the first (default) AND         relationship between the source IP and L4 protocol type in the         Anti-Scan's footprint rule.

Generality flag—Together with the accuracy score, the worm's footprint rule is assigned with a flag that represents the level of its generality. There are three generality levels:

-   -   1. Generic (g)—Totally generic rule. This means that the attack         footprint can be effective for all networks that are registered         in the “automatic signature propagation service.”     -   2. Generic/source (s)—The generality of the worm footprint rule         is limited to a source network (the generic signature includes a         source IP address). This signature is effective only in blocking         attack traffic that originates in the same source IP address as         specified by the agent device that created the attack footprint         rule (i.e., same attack from other sources will not be blocked).         This option can fit the requirements of large internal networks.     -   3. Generic/target (t)—The generality of the worm footprint rule         is limited to a target network (the generic signature includes         destination IP address(es)). This means that the attack         footprint is relevant only for certain networks such as:         -   a) Multiple devices that protect a few internet links of the             same target network.         -   b) Multiple devices located in the internal network, or in             the internet gateway of the same network and/or in the             upstream (e.g., ISP) that provides the Internet services to             the same target network (i.e., all protect the same network             IP range).         -   3. Both (b)—The generality of the footprint rule is limited             to a combination of certain target and origin networks.

Worm characteristic level—The footprint rule is assigned with a worm characteristic level according to the existing footprint types:

-   -   1. High—high probability that the attack footprint represents         worm propagation activities.     -   2. Medium—medium probability.     -   3. Low—The attack footprint represents network scanning tool         (not a worm).

It should be noted that this worm characteristic level, even if set to high, doesn't insure that the detected attack contains worm propagation. However, when the characteristic is set low, one can be “confident” that the detected network scan isn't associated with a worm activity.

FIG. 12 illustrates the Anti-scan worm characterization process. The flow chart of FIG. 12 illustrates rules that are used in order to decide about the worm characteristic level.

Attack direction—An attack direction flag will be assigned to each footprint rule. Possible values are: Inbound, outbound and N/A (not applicable).

FIG. 13 summarizes the above-mentioned anti-scan footprint rule characterization process. It should be noted that attack system time will be assigned to each new generic signature.

Generic Signatures Black List

This generic signatures black list includes all automatic generic signatures generated by the B-DoS and Anti-scan modules and were delivered through the external generic signature update interface.

The generic signatures black list filters are divided into two filter types:

-   -   1. B-DoS generic signature filter     -   2. Anti-Scan generic signatures filters

Each list maintains its own generic signatures. Each signature is maintained in one of three states: block state, detection state and trace state.

Block state: during block state, packets that match the signature will be dropped and an alert will be raised.

Detection state: During detection state, packets that match the signature will be forwarded and an alert will be raised.

Trace state: In this state, statistics information is gathered per generic signature. Statistics information includes: packets per second, bytes per second and direction (inbound/outbound). These statistics are sent (typically every 60 seconds) to the controller. The controller will use these statistics for attack trace analysis purposes—Trace analysis will be defined later on.

The duration in which a signature is kept in each one of the states (block, detection or/and trace) is handled by the controller (i.e., the controller actually maintains the signatures states).

Trace State Signatures

Trace signatures are used to detect the route and source (or the nearest detectable source) of the attack.

According to configuration, the controller will decide if to send a generic signature to other device agents with a “trace state.” Trace state time-out is controlled by the controller.

Trace State Rules

Each trace generic signature is assigned with two counters: PPS [Packet per Second] and Bps [Bytes/sec]. These counters are incremented upon each signature hit.

Every predefined time interval (default: 60 seconds), the average of PPS and Bps will be sent to the controller.

In case that the number of Bps or PPS (in one second interval) breaches a certain threshold (Th_(Trace)), the agent device will send immediately to the controller an “urgent” trace message that includes the last second counters and the updated counters' average.

It should be noted that:

-   -   Currently, trace signatures refer only to B-DoS (i.e., DoS and         DDoS floods) attack filters.     -   A generic signature can be simultaneously in two states such as:         trace state and block state or trace and detection state (the         controller can decide about that).     -   The controller can decide if to remove a signature from the         trace state and add it to block state. This process will be         further explained later in the propagation rules section.     -   Th_(Trace) will be calculated per trace signature as follow:         Th _(Trace) ^(PPS)=dist[%]×(PPS _(FILTER))         Th _(Trace) ^(Bps)=dist[%]×(Bps _(FILTER))         where,     -   dist≡Portion percentages [1-100%]—Configurable parameter.     -   PPS_(Filter)≡The number of packets per second that was assigned         to the generic signature in the agent device that created it         (i.e., attack rate in packets per second).     -   Bps_(Filter)≡The number of bytes that were assigned to the         generic signature in the agent device that created it (attack         rate in Bytes per second).

The condition will be checked every one second as follow:

-   -   If         Bps=>Th _(Trace) ^(Bps) OR PPS=>Th _(Trace) ^(PPS), then,     -   send “urgent” trace statistics message to the controller, else,         return.

Generic Signature List Time-Out

The generic signature list inside each agent device will be supported by an internal expiration mechanism, i.e., all generic signatures will be removed after a pre-defined time-out.

The time-out mechanism will be activated only when there is a failure to communicate with the controller (i.e., no reply from the primary and secondary controllers—the controller operations are described later on). The time-out will be reset when the communication with the controller is re-established.

Blocking Rules

Rate-Limit (Manual)

Block state includes rate-limit blocking mechanism (PPS rate limiting). Rate limit can be configured manually per each generic signature and, globally, for all generic signatures that are from the same type (i.e., DoS/DDoS generic signatures and Anti-scan/worm generic signatures). Full blocking is implemented when rate-limit value is set 0 (the default value).

Automatic Rate-Limit

This mechanism automatically sets the rate-limit value according to the generic signature characteristic parameters. Rate-limit values will be typically set as per Tables 10-11 below:

TABLE 10 Anti-Scan Signatures (optional mechanism) Signature's characteristic Level parameter Low Medium High Very High Worm level 100 PPS 10 PPS  0 PPS — Accuracy 100 PPS 50 PPS 10 PPS 0 PPS level

In case that the rate-limit values are not the same (e.g., Worm level=medium and Accuracy level=Low), the maximum value between the two will be set.

TABLE 11 B-DoS signatures Signature's characteristic parameter Very Low Low Medium High Very High Accuracy level 1000 PPS 500 PPS 100 PPS 10 PPS 0 PPS

It should be noted that:

-   -   Above values in tables 10 and 11 are for illustration only.     -   In one embodiment, an option to configure the rate-limit value         per characterization parameter is implemented.     -   In case that both manual and automatic rate limit options are         enabled, the rate limit value will be set according to the         higher value between the two.     -   The motivation behind the automatic rate limit is to set lower         rate limit values (i.e., more intensive mitigation) as long as         the generic signature is assigned with higher accuracy level or         higher worm characteristics score/level. Otherwise, the system         will use more “gentle” mitigation actions (i.e., higher rate         limit values which means less intensive blocking).

Generic Signature Propagation

Signature propagation is enabled through the controller. Each agent device is configured to send generic signatures to the controller which is responsible for distributing the signatures to other devices according to a pre-defined propagation rules. Propagation rules are configured in the controller.

In order to make the configuration process easier, default propagation rules profiles are implemented in the controller. Each profile represents a different generic signature propagation scenario. Customization of the existing profiles' rules and the creation of new profiles are within the present invention.

Signature Propagation Flow

FIG. 14 illustrates signature propagation flow as per the teachings of the present invention. When a new generic footprint 1402 arrives to the controller, it is checked through the propagation rules 1404. In case that the footprint's characteristics comply with the rule's conditions, an action is applied. The action specifies which generic signature list(s) should be updated with the new generic footprint. It should be noted that a new footprint can comply with more than one propagation rule.

The controller updates the relevant generic signature list(s) and sends it to the relevant agent device(s). In the case shown in FIG. 14, the controller updates signature lists 1406, 1408, 1410, and 1412 for agent devices 2 and 5, 6, and 7, respectively. Next, update mechanism 1414 communicates this information with appropriate agent devices (in this case, device 2, device 5, device 6, and device 7).

Messages (Protocol)

The following section defines the messages sent from and to the controller.

Table 12 below lists the agent device messages (messages that are initiated by the agent device).

TABLE 12 Direction: # Message type Content Interval/trigger 1 Agent to Controller: 1. Message ID Sent upon filter New signature 2. System time (GMT time) creation update 3. Agent's source IP (area code if exist) 4. Filter (including all characteristics) 5. Filter type (Anti scan or B-DoS) 2 Controller to Agent: 1. Message ID New signature reply 2. System time (GMT time) 3. Status (ok, error) 4. Filter status (new/exist) 5. Unique filter ID 3 Agent to Controller: 1. Message ID Predefined period Periodic trace stat 2. Agent's source IP (area code if exist) (default of 60 sec) update 3. System time (GMT time) 4. Filter unique ID 5. Trace stat (PPS, bps) 4 Agent to Controller: 1. Message ID Upon event “Urgent” trace stat 2. Agent's source IP (area code if exist) update 3. System time (GMT time) 4. Filter unique ID 5. Trace stat (Average and last second PPS and bps) 5 Controller to Agent: 1. Message ID Trace reply 2. System time 3. Status (ok, error) 4. Filter unique ID 8 Agent to Controller: 1. Message ID Predefined period Keep alive update 2. System time (GMT time) (default 60 sec) 3. Agent's source IP (area code if exist) 4. Signature list cookie 5. IDS version 6. Protocol version 9 Controller to Agent: 1. Message ID Keep alive reply 2. System time 3. Status (ok, error) 4. Signature list update (if needed according to cookie). 5. New cookie 10 Agent to Controller: 1. Message ID Upon configuration Full signature list 2. System time (GMT time) request request 3. Agent's source IP 4. IDS version 5. Protocol version 11 Controller to Agent: 1. Message ID Full list reply 2. System time 3. Status (ok, error) 4. Last updated signature list 5. Cookie

Upon arrival of a new signature, the controller assigns to it a unique ID.

FIG. 15 illustrates a timing diagram outlining a typical Agent device—Controller message exchange.

Agent Device Message Sequence

When an agent device is going up (i.e., after a boot sequence) and in case that the generic signature propagation feature is enabled, it will start sending keep alive messages to the primary controller.

The agent device maintains messages retransmit mechanism for the new signature message and “urgent” trace statistics message. This mechanism includes a retransmit time-out (RTO). Default RTO will be 15 seconds.

In case that the RTO is expired or in the case of a controller error message (i.e., error is treated as no reply) the agent device will retransmit the last message. In case that the number of retries exceeds a pre-defined limit (default of 3), the RTO will be extended (e.g., 60 seconds). The RTO will be set to its default value after the message is acknowledged by the controller.

It should be noted that:

-   -   RTO and number of retries can be defined through configuration         (in the agent device).     -   Because of NAT/proxy issues, all messages should include (in         application payload) the source IP addresses of the agent device         in the message content.     -   Specifying the unique signature ID inside the controller reply         messages is optional.

Table 13 outlines the controller messages (messages that are initiated by the controller).

TABLE 13 Direction: # Message type Content Interval/trigger options 1 Controller to Agent: 1. Message ID a. Upon each modification to the Signatures list update 2. System time (GMT)    signature list. 3. New filter list (cookie) b. Non-updated agent device (i.e., old 4. Signature's state [Block,    cookie)    detection] - the state is specified c. Agent device full signature list    per signature.    request 2 Agent to Controller: 1. Message ID New list reply 2. System time 3. Status (ok, error) 3 Controller to Agent: 1. Message ID a. Upon each modification to the trace Trace signatures list 2. System time (GMT)    signature list update 3. New trace list (cookie) b. Non-updated agent device (trace    cookie check) c. DP device trace signature list    request 4 Agent to Controller: 1. Message ID Trace update reply 2. System time (GMT) 3. Status (ok, error)

FIG. 16 illustrates a timing diagram outlining the Controller's message exchange.

It should be noted that:

-   -   Retransmit mechanism—RTO and number of retries will be defined         in the controller (configurable). In case of error reply from         the agent device, the same retransmit mechanism will be used         (i.e., error will be treated as no reply).     -   Retransmit process will stop after pre-defined retries.     -   In case the controller is in the procedure of sending retries         messages to the agent device (following agent device error reply         or non-reply) and the associated signature list is updated in         the same time, then the controller will reset the retries         counter (i.e., allowed number of retries) and will send the         updated signature list.

Cookies

There are two types of signature lists that are maintained in the controller. One is the trace signatures and the other is the block signatures. The block signature list includes signatures that are in a block or detection state. These signature lists are supposed to reflect the signatures list at each agent device (i.e., a copy).

In case a new signature is added to the signature list of one or more agent devices (according to a pre-defined propagation rules in the controller), the controller sends an updated signature list to the relevant agent device(s). The signature list update includes all signatures including the new one(s). The agent device that receives the updated list will insert the new signatures, remove non-existing signatures and will ignore signatures that are already exist in his own list (these will be identified according to the filter unique ID).

Each new update message includes a cookie. The cookie's value is an identifier of the current (last updated) signature list that is associated to a specific agent device. In case that the agent device sends a keep alive message without the last cookie value that is set in the controller, then the controller will send the last update message again.

Each agent device starts with an “initial” cookie value (e.g., zero). This value is run over by the first cookie value that is sent from the controller.

It should be noted that:

-   -   The controller maintains a separate signature lists and cookie         values per each agent device.     -   The controller maintains a separate signature lists for         block/detection signatures and trace signatures (i.e., also two         cookies).

Signature Blocking Time-Out

The controller is responsible to maintain an oblivion period for each one of the signatures per signature list.

The oblivion period insures that the signature list maintains signatures during attack outbreaks and automatically removes them, gradually through a transit in a detection state, when they become less relevant (i.e., when the attack outbreak become remote in time). The following time-out mechanism is supported in the controller:

Block/Detection States

FIG. 17 illustrates generic signature states (i.e., block state 1702, detection state 1704, and removed ‘virtual’ state 1706) and transition rules.

It should be noted that:

-   -   Oblivion periods (A and B) are configurable per filter type         (i.e., Anti scan and B-DoS generic signatures).     -   Transition from state to state can be forced through         configuration (per filter in the signature list)     -   Any transition to block or detection states initializes the         oblivion period.     -   In case oblivion period (A or B) is expired, the generic         signature will be removed and a new cookie will be generated for         the associated generic signatures list.     -   In case of that the generic signatures have allocated all         available memory, the “oldest” signature in the list will be         automatically removed.

Trace State

FIG. 18 illustrates generic signature trace states and the transition rules. Trace signatures are used to detect the route and source (or the nearest detectable source) of the attack. According to configuration, the controller will decide if to send a generic signature to other agent devices with a “trace state” action. Trace state time-out (oblivion period C) is defined according to configuration (the default time-out is shorter than the block and detection states' time-out).

Trace state rules:

-   -   a) In case oblivion period (C) is expired, the generic signature         will be removed and a new cookie will be generated for the         associated generic signatures list.     -   b) The controller receives periodically (every 60 seconds) trace         statistics messages from the agent device. In case that an         “urgent” trace update was received, then the oblivion period (C)         of the associated generic signature will be renewed.

It should be noted that currently, trace signatures refer only to B-DoS attacks filters (i.e., DoS/DDoS).

Registration and Recovery

Any agent device that “wants” to be part of the automatic signature propagation network is registered at the controller.

Registration is done through configuration in the controller and in the agent device.

The agent device is configured with the IP address of the primary and secondary controllers.

The primary controller is configured with the agent's IP address and an area code that the device is belonged to (area code configuration is optional).

Upon registration, the agent device sends keep-alive messages with an initial cookie value. The controller sets the agent as an active device and, in case that there are pending signatures associated with this device, sends a signature list update message.

The controller maintains a distribution list that includes all registered agent devices and distributes the newly generated signatures only to active devices according to a pre-defined propagation rules.

In case an agent device is detected to be down for some reason (this will be identified according to keep-alive time-out), the controller changes the status of this device to “inactive” and will stop sending messages to this device. The controller will set the device back to active when a keep-alive message is identified again.

FIG. 19 illustrates a timing diagram showing the registration process between an agent device and a controller.

Controller Backup (Active-Passive)

In order to maintain high availability capabilities, the signature propagation mechanism may be supported by two controllers, i.e., a primary controller and secondary (back up) controller.

The secondary controller maintains a copy of the distribution list, propagation rules and generic signature lists of the primary controller. The primary and secondary controllers are synchronized in a pre-defined interval and upon any change in the primary controller. Each agent device is configured with the IP addresses of both primary and secondary controllers.

Keep-Alive

The communication mechanism between the primary and secondary controllers includes keep-alive messages that are sent from the primary to the secondary. In case that a keep-alive time-out is expired, the secondary is set to be the primary controller. In this case a message that updates all agent devices about the new primary device is sent by the new primary controller (e.g., set secondary to primary command).

FIG. 20 illustrates a timing diagram showing the interaction between the primary and secondary controllers.

In order to keep both signature lists (in the primary and secondary) synchronized, the agent device will never send a new generic signature message to the secondary controller unless the secondary has sent a primary update message.

The agent device ignores any message that comes from a secondary device unless it is a primary update message (see FIG. 21).

FIG. 21 illustrates a timing diagram showing an agent device and Secondary Controller recovery scenario.

Primary and Secondary Controllers Update Messages

The primary controller is responsible to update the secondary device upon every change in the signature list (including a periodic update). In any case, the secondary controller replies to the primary's keep-alive message with a cookie that represents the last update. In case that the primary identifies that the cookie doesn't match the most updated one, an update message will be sent again.

Security Considerations

To avoid session hijacking and insertion of fake signatures and distribution lists, all communication channels between the automatic signature propagation network components may include tight authentication mechanisms.

Signature Lists

The controller maintains a signature list per registered agent device. Each signature list reflects the generic black list in the associated agent device.

The signature list includes the following parameters:

-   -   1. agent IP address     -   2. Area code     -   3. Cookie     -   4. Generic signature lists (trace and block lists)         -   a. Generic signature and its associated characteristics         -   b. unique ID per generic signature         -   c. Signature state: block or detection (trace signature has             only one state)         -   d. Generic signature time-out

Through these lists, the controller will be able to control the propagation of a signature to each agent device.

Propagation Rules

Propagation rules are configured in the controller. It is possible to configure basic and advanced propagation rules as follow:

Basic Propagation Rules

A basic propagation rule follows the format shown in Table 14:

TABLE 14 From Actions device Filter Accuracy Worm Generic Distribution IP Distribution Rule # IP Area type Level Level type Direction range area Filter State 1 B B-DoS =>L =>M g OR s Inbound 10.0.0.1-10.0.0.5 A Block

-   -   a) Rule #—Rules are checked in order of their rule number.

Rule Conditions

-   -   b) From device—This field specifies the agent device that has         created the generic signature. Code area* or/and IP address         should be specified in this field.     -   c) Filter type—Type of filter that this rule applies to.         Possible values are B-DoS or Anti-Scan     -   d) Accuracy level—The generic signature accuracy level that this         rule applies to. Possible values are from very low to very high         (depends on the filter type). Possible operators are: =>, = and         =<.     -   e) Worm level—The worm level that this rule applies to. Possible         values are Low, medium and high. Possible operators are: =>, =         and =<.     -   f) Generic type—the generic type that this rule applies to.         Possible values are source, destination or generic. OR may be         defined between these types, e.g., g OR s.     -   g) Direction—Attack direction that this filter was associated         with at the time it was created in the agent device. Possible         values are inbound, outbound, inbound OR outbound or N/A (Not         Applicable).

Rule Actions

-   -   h) Actions—The actions that should be taken in case all filter         parameters have met the rule criteria. Possible actions are:         -   1. Add to distribution list—specify the range of IP             addresses (or area code) of the agent devices that the             signature should be propagated to.         -   2. State—The specific signature action that should be taken             in each agent device.

Possible values are: trace block or detection.

*Area Code—The area code represents the protected network area from which the new generic signature rule has been generated (i.e., the network, cluster or any other virtual area in which the agent device was deployed in).

It should be noted that the area code is a group of agent devices. It is configured in the controller (i.e., associate agent device IP addresses with an area code). This area code is part of the propagation rules between agent devices (e.g., between network areas).

Advanced Propagation Rules

Advanced propagation rules will allow the network manager to configure rules that will, first, track attacks to their nearest source (i.e., through trace signatures) and then, according to the trace results, will distribute or switch signatures from a trace state to a block state only in the most relevant agent devices (i.e., devices that were discovered to be the most effective “mitigators”). The nearest source will be determined automatically according to the activity level of each trace signature.

Another advanced option is to allow adding additional footprint types and values into an existing generic signature (only through AND logical expression). This option is called ‘generic signature modification’ advanced rule.

Table 15 below depicts the advanced propagation rule format (generic signature modification):

TABLE 15 From Advanced actions device Filter Accuracy Worm Generic Distribution IP Distribution Add footprint Filter Rule # IP Area type Level level type Direction range area type State 1 B B-DoS =>H =>H g Inbound 10.0.0.1-10.0.0.5 A Destination IP Block

Advanced propagation rule format (conditional action rules):

TABLE 16 From Advanced actions device Filter Accuracy Worm Generic Distribution IP Distribution Trace Filter Rule # IP Area type Level level type Direction range area condition State 1 B B- =>H =>H g Inbound 10.0.0.1-10.0.0.5 A =>80% Trace DoS to Block 2

The last rule (table 16) means that a generic signature that arrived from area B agent devices and have the specified characteristics (i.e., accuracy, worm level, etc) will be added to a distribution list of agent devices in area A (10.0.0.1 to 10.0.0.5). The action is to propagate these signatures in a trace mode to area A. These generic signatures will be transited into block state case the trace condition occurs (e.g., If trace statistics=>80% attack rate, then switch to Block).

Switching from trace to block actually means that the controller should remove the signature from the trace list and add it to the generic block list (in block state).

Manual Propagation Rules

An option to choose a generic signature from any one of the generic signature list and to push it to any agent device is included as well (regardless to the existing propagation rules).

Propagation Profiles

Horizontal Inbound Propagation Profile

FIG. 22 illustrates a horizontal signature propagation scenario (e.g., carrier/ISP environment). The profile includes examples of both propagation rules and typical agent device configuration parameters.

The following propagation rules in Table 17 is part of the pre-defined horizontal inbound propagation profile:

TABLE 17 Actions From device Filter Accuracy Worm Generic Distribution Distribution Rule # IP Area type Level level type Direction IP range area Filter State 1 10.0.0.1-10.0.0.3 A B-DoS =>M =>M g OR s Inbound 10.0.0.1-10.0.0.3 A Block 2 10.0.0.1-10.0.0.3 A Anti- =>M* =>H G OR s Inbound 10.0.0.1-10.0.0.3 A Block Scan 3 10.0.0.1-10.0.0.3 A B-DoS <L =>L G OR s Inbound 10.0.0.1-10.0.0.3 A Detection

In this case if agent device 1 detects an inbound attack and generated a generic signature then the signature is propagated (if it complies with all rules) to other agent devices in area A, thus creating a pro-active protection for client 2 and 3 networks as well.

The following device configuration parameters in Table 18-19 is part of the horizontal profile. Footprint types configuration parameters:

TABLE 18 Inbound horizontal profile - B-DoS Footprint parameters IGMP # Footprint Type TCP configuration UDP configuration ICMP configuration configuration 1 TCP Sequence Number Enabled — — — 2 Transport Checksum — Disabled Disabled Disabled 3 IP ID number Enabled Enabled Enabled Enabled 4 DNS ID number (port — Enabled — — 53) 5 DNS Qname (port 53) — Disabled — — 6 DNS Qcount (port 53) — Enabled — — 7 Source Port Dynamic Dynamic — — 8 Source IP address Dynamic Dynamic Dynamic Dynamic 9 ToS (Type of Service) Enabled Enabled Enabled Enabled 10 Packet Size Enabled Enabled Enabled Enabled 11 Fragment Disabled Disabled Disabled Disabled 12 Fragment offset Enabled — — — 13 Destination Port Enabled Enabled — — 14 Destination IP address Disabled Disabled Disabled Disabled 15 ICMP Message Type — — Enabled — 16 IGMP Message Type — — — Enabled 17 TTL Disabled Disabled Disabled Disabled

TABLE 19 Inbound horizontal profile - Anti scan footprint parameters TCP UDP ICMP # Footprint Type configuration configuration configuration 1 TCP Sequence Number Enabled N/R N/R 2 IP ID number Enabled Enabled Enabled 3 Source IP address Dynamic Dynamic Dynamic 4 Packet Size Enabled Enabled Enabled 5 Destination Port Enabled Enabled — 6 Destination IP address Disabled Disabled Disabled 7 TTL Disabled Disabled Disabled

Consistency Parameters:

B-DoS: DTh=60 seconds

Anti-Scan: DTh=30 seconds, FTh=10 Hz (time between events<=0.1 sec)

Horizontal Outbound Propagation Profile

Propagation rules in Table 20 are part of the horizontal outbound propagation profile:

TABLE 20 Actions From device Filter Accuracy Worm Generic Distribution Distribution Rule # IP Area type Level level type Direction IP range area Filter State 1 10.0.0.1-10.0.0.3 A Anti- =>M* =>H g OR s Outbound 10.0.0.1-10.0.0.3 A Block Scan 2 10.0.0.1-10.0.0.3 A B-DoS =>M =>H g OR s Outbound 10.0.0.1-10.0.0.3 A Block 3 10.0.0.1-10.0.0.3 A B-DoS <L =>H g OR s Outbound 10.0.0.1-10.0.03 A Detection

Footprint and consistency parameters are the same as in the case of the inbound profile.

Horizontal Inbound and Outbound Profile

The default profile for both inbound and outbound horizontal propagation rules is actually an aggregation of both default profile rules. See the example given below in Table 21:

TABLE 21 Actions From device Filter Accuracy Worm Generic Distribution Distribution Rule # IP Area type Level level type Direction IP range area Filter State 1 10.0.0.1-10.0.0.3 A B-DoS =>M =>M g OR s Inbound 10.0.0.1-10.0.0.3 A Block 2 10.0.0.1-10.0.0.3 A Anti- =>M* =>H g OR s Inbound 10.0.0.1-10.0.0.3 A Block Scan 3 10.0.0.1-10.0.0.3 A B-DoS <L =>L g OR s Inbound 10.0.0.1-10.0.0.3 A Detection 4 10.0.0.1-10.0.0.3 A Anti- =>M* =>H g OR s Outbound 10.0.0.1-10.0.0.3 A Block Scan 5 10.0.0.1-10.0.0.3 A B-DoS =>M =>H g OR s Outbound 10.0.0.1-10.0.0.3 A Block 6 10.0.0.1-10.0.0.3 A B-DoS <L =>H g OR s Outbound 10.0.0.1-10.0.0.3 A Detection

Vertical Inbound Propagation Profile

FIG. 23 illustrates the vertical signature propagation scenario (e.g., carrier upstream mitigation scenario).

Propagation rules in Table 22 are part of the vertical inbound propagation profile:

TABLE 22 From Actions device Filter Accuracy Worm Generic Distribution Distribution Rule # IP Area type Level level type Direction IP range area Filter State 1 10.0.0.1, A B-DoS =>H =>L g OR s Inbound 10.0.0.2-10.0.0.4 B Block 10.0.0.5, 10.0.0.6 2 10.0.0.1, A Anti- =>M =>H g OR s Inbound 10.0.0.2-10.0.0.4 B Detection 10.0.0.5, Scan 10.0.0.6 3 10.0.0.1, A B-DoS =M =>L g OR s Inbound 10.0.0.2-10.0.0.4 B Detection 10.0.0.5, 10.0.0.6

The vertical profile is mainly effective to mitigate attacks that were detected at the customer side (i.e., customer edge) but requires upstream mitigation (e.g., mitigation at the ISP), thus effectively preventing attacks that consume all of the customer's bandwidth resources (bandwidth consumption).

Device configuration parameters in Tables 23-24 will be part of the vertical profile.

Footprint types configuration parameters:

TABLE 23 Inbound vertical profile - B-DoS Footprint parameters UDP ICMP IGMP # Footprint Type TCP configuration configuration configuration Configuration 1 TCP Sequence Number Enabled — — — 2 Transport Checksum — Disabled Disabled Disabled 3 IP ID number Enabled Enabled Enabled Enabled 4 DNS ID number (port — Enabled — — 53) 5 DNS Qname (port 53) — Disabled — — 6 DNS Qcount (port 53) — Enabled — — 7 Source Port Dynamic Dynamic — — 8 Source IP address Dynamic Dynamic Dynamic Dynamic 9 ToS (Type of Service) Enabled Enabled Enabled Enabled 10 Packet Size Enabled Enabled Enabled Enabled 11 Fragment Disabled Disabled Disabled Disabled 12 Fragment offset Enabled — — — 13 Destination Port Enabled Enabled — — 14 Destination IP address Dynamic Dynamic Dynamic Dynamic 15 ICMP Message Type — — Enabled — 16 IGMP Message Type — — — Enabled 17 TTL Disabled Disabled Disabled Disabled

TABLE 24 Inbound vertical profile - Anti scan footprint parameters TCP UDP ICMP # Footprint Type configuration configuration configuration 1 TCP Sequence Number Enabled N/R N/R 2 IP ID number Enabled Enabled Enabled 3 Source IP address Dynamic Dynamic Dynamic 4 Packet Size Enabled Enabled Enabled 5 Destination Port Enabled Enabled — 6 Destination IP address Disabled Disabled Disabled 7 TTL Disabled Disabled Disabled

Consistency Parameters:

B-DoS: DTh=60 seconds

Anti-Scan: DTh=30 seconds, FTh=10 Hz (time between events<=0.05 sec)

Vertical and Horizontal Inbound Propagation Profile

FIG. 24 illustrates vertical and horizontal propagation scenario (carrier environment).

The default profile for both vertical and horizontal propagation rules is actually an aggregation of both default profile rules, as shown below in Table 25.

TABLE 25 Actions From device Filter Accuracy Worm Generic Distribution Distribution Rule # IP Area type Level level type Direction IP range area Filter State 1 10.0.0.1, A B-DoS =>H =>L g OR s Inbound 10.0.0.2-10.0.0.4 B (vertical) Block 10.0.0.5, 10.0.0.6 2 10.0.0.1, A Anti- =>M =>H g OR s Inbound 10.0.0.2-10.0.0.4 B (vertical) Detection 10.0.0.5, Scan 10.0.0.6 3 10.0.0.1, A B-DoS =M =>L g OR s Inbound 10.0.0.2-10.0.0.4 B (vertical) Detection 10.0.0.5, 10.0.0.6 4 10.0.0.1, A B-DoS =>M =>M g OR s Inbound 10.0.0.1, A Block 10.0.0.5, 10.0.0.5, (Horizontal) 10.0.0.6 10.0.0.6 5 10.0.0.1, A Anti- =>M =>H g OR s Inbound 10.0.0.1, A Block 10.0.0.5, Scan 10.0.0.5, (Horizontal) 10.0.0.6 10.0.0.6 6 10.0.0.1, A B-DoS <L =>L g OR s Inbound 10.0.0.1, A Detection 10.0.0.5, 10.0.0.5, (Horizontal) 10.0.0.6 10.0.0.6 7 10.0.0.2-10.0.0.4 B B-DoS =>M =>M g OR s Inbound 10.0.0.2-10.0.0.4 B Block (Horizontal) 8 10.0.0.2-10.0.0.4 B Anti =>M =>H g OR s Inbound 10.0.0.2-10.0.0.4 B Block Scan (Horizontal) 9 10.0.0.2-10.0.0.4 B B-DoS <L =>L g OR s Inbound 10.0.0.2-10.0.0.4 B Detection (Horizontal)

The above profile also includes the case in which one of the devices in area B (i.e., upstream devices) generate new attack generic signature. In this case, all other devices in area B will be horizontally updated.

Trace Inbound Propagation Profile

FIG. 25 shows typical trace propagation scenarios (carrier, network provider or ISP) environment).

The default advanced propagation rules in Table 26 reflect typical trace scenarios:

TABLE 26 Actions From device Filter Accuracy Worm Generic Distribution Distribution Rule # IP Area type Level level type Direction IP range area Filter State 1 10.0.0.1, A B-DoS =>M =>L g OR s Inbound 10.0.0.2-10.0.0.6 — Trace* 10.0.0.5, OR t 10.0.0.6 *Conditional action rule If trace statistics =>90% attack rate, then switch to Block

In the scenario above an inbound attack was detected by agent device in client 1 (agent device 1). The new generic signature was propagated to all other agent devices in trace mode (i.e., 10.0.0.2-10.0.0.6).

Agent device 6 (client 3) has detected an intensive trace footprint activity (i.e., more than 90% PPS or Bps of the detected attack rate at customer 1) which means that the main origin of the attack is client 3. According to the advance action rule, the controller adds the trace generic signature to the generic block list (in block state) in agent device 6 (10.0.0.6).

In this way, the system blocks the attack at the nearest point to its center of gravity (i.e., nearest point to the attack's origin).

It should be noted that:

-   -   In case of trace scenario, blocking direction can be selected         according to trace activities, e.g., if the trace generic         signature identifies activity in only one direction then the         blocking should apply at the same traffic direction. The         scenario in FIG. 25 requires that switching from trace to block         will apply only to outbound direction (i.e., attack that origin         in client 3 will be blocked in the outgoing direction).     -   When using multiple propagation profiles there is a chance for         conflict between the profiles' default footprint type         configuration parameters and/or consistency parameters.         Conflicts will be solved according to the following rules:

Footprint type parameters:

-   -   1. Disabled and Dynamic—Disabled will be applied     -   2. Disabled and enabled—Disabled will be applied     -   3. Enabled and Dynamic—Dynamic will be applied

Consistency Parameters:

-   -   1. DTh: max DTh will be chosen     -   2. FTh: max FTh will be chosen

Embodiments herein may be implemented in a computer program code-based product, which is a storage medium having program code stored therein which can be used to instruct a computer to perform any of the methods associated with the present invention. The computer storage medium includes any of, but is not limited to, the following: CD-ROM, DVD, magnetic tape, optical disc, hard drive, floppy disk, ferroelectric memory, flash memory, ferromagnetic memory, optical storage, charge coupled devices, magnetic or optical cards, smart cards, EEPROM, EPROM, RAM, ROM, DRAM, SRAM, SDRAM, or any other appropriate static or dynamic memory or data storage devices.

CONCLUSION

A system and method has been shown in the above embodiments for the effective implementation of a signature propagation network. While various preferred embodiments have been shown and described, it will be understood that there is no intent to limit the invention by such disclosure, but rather, it is intended to cover all modifications and alternate constructions falling within the spirit and scope of the invention. 

What is claimed is:
 1. A method implemented in a network including a plurality of intelligent security agents distributed across the network, comprising: identifying an on-going attack through behavioral analysis protection in said network; creating a generic attack signature of at least one of a denial-of-service (DoS) attack and a worm attack through said behavioral analysis by at least one of said plurality of intelligent security agents; sending said created generic attack signature to a controller; wherein said controller: receives said created generic attack signature from one of the plurality of intelligent security agents, matches said created generic attack signature to a plurality of propagation rules, selects one or more of said plurality of intelligent security agents to propagate said created generic attack signature to, when the said created generic attack signature matches at least one of the plurality of propagation rules, and propagates said created generic attack signature to the selected one or more of said plurality of intelligent security agents, wherein a blacklist associated with each of the selected one or more of said plurality of intelligent security agents is dynamically updated with the at least one propagated created generic attack signature, wherein each of said plurality of propagation rules defines at least one or more of the plurality of intelligent security agents that the created generic attack signature is propagated to, based in part on the intelligent security agent that created said generic attack signature, and attributes of said generic attack signature, wherein said attributes include at least one of the following attributes: an accuracy level of signature, a worm characteristic level, an attack rate, an attack direction, and a generality type.
 2. The method of claim 1, wherein a generic attack signature rule is generated from multiple footprint types with each footprint type assigned an accuracy score and based on that a generic attack signature accuracy score is set.
 3. The method of claim 2, wherein said generic attack signature rule is assigned with an attribute representing three generality levels: (1) generic for attack signatures that are effective for all registered networks; (2) generic/source for attack signatures that are effective in blocking attack traffic originating from a source network; and (3) generic/target for attack signatures limited to a target network.
 4. The method of claim 2, wherein said generic attack signature is assigned a dynamic worm score, wherein said worm score is set based on a positive or negative score weight function and the footprint types and values included in the generic attack signature.
 5. The method of claim 1, wherein said at least one network is at least one of: a local area network, a wide area network, and the Internet.
 6. A method implemented in a controller communicating with a plurality of intelligent security agents distributed across a network, said method comprising: receiving at least one created generic attack signature of at least one of a DoS attack and a worm attack from an intelligent security agent over said network, said attack generic attack signature created through behavioral analysis; propagating, based on attributes of the generic attack signature and propagation rules, said received at least one created generic attack signature to one or more of said plurality of intelligent security agents, wherein a blacklist associated with each of said plurality of intelligent security agents distributed across said network is dynamically updated with said propagated at least one created generic attack signature, said update performed via an external update mechanism associated with each of said plurality of intelligent security agents distributed across said network, wherein each of said propagation rules defines at least one or more of the plurality of intelligent security agents that the created generic attack signature is propagated to, based in part on the intelligent security agent that said created generic attack signature, and said generic attack signature attributes parameters, wherein said generic attack signature parameters include at least one of the following attributes: an accuracy level of signature, a worm characteristic level, an attack rate, an attack direction, and a generality type.
 7. The method of claim 6, wherein a generic attack signature rule is generated from multiple footprint types with each footprint type assigned an accuracy score and based on that a generic attack signature accuracy score is set.
 8. The method of claim 7, wherein said generic attack signature rule is assigned an attribute representing three generality levels: (1) generic for attack signatures that are effective for all registered networks; (2) generic/source for attack signatures that are effective in blocking attack traffic originating from a source network; and (3) generic/target for attack signatures limited to a target network.
 9. An article of manufacture comprising a non-transitory computer usable medium having computer readable program code embodied therein, said medium comprising: computer readable program code for identifying at least one of denial-of-service (DoS) attacks and worm attacks based on behavioral analysis; computer readable program code for creating a generic attack signature that characterizes said attacks through said behavioral analysis based on attack signature information regarding the at least one of DoS attacks and worm attacks; computer readable program code for sending said created generic attack signature to a controller; wherein said controller: receives said created generic attack signature from one of the plurality of intelligent security agents, matches said created generic attack signature to a plurality of propagation rules, selects one or more of said plurality of intelligent security agents to propagate said created generic attack signature to, when the said created generic attack signature matches at least one of the plurality of propagation rules, and propagates said created generic attack signature to the selected one or more of said plurality of intelligent security agents, wherein a blacklist associated with each of the selected one or more of said plurality of intelligent security agents is dynamically updated with the at least one propagated created generic attack signature, wherein each of said plurality of propagation rules defines at least one or more of the plurality of intelligent security agents that the created generic attack signature is propagated to, based in part on the intelligent security agent that created said generic attack signature, and attributes of said generic attack signature, wherein said attributes include at least one of the following attributes: an accuracy level of signature, a worm characteristic level, an attack rate, an attack direction, and a generality type.
 10. The article of manufacture of claim 9, wherein said non-transitory computer readable program code additionally generates a generic attack signature rule from multiple footprint types with each footprint type assigned an accuracy score and based on that a generic attack signature accuracy score is set.
 11. A distributed security system comprising: a plurality of intelligent security agents distributed across a network, said intelligent security agents comprising: a blacklist identifying a plurality of signatures used in restricting packet flow in said network; a generic attack signature creating module to create a generic attack signature through behavioral analysis; a propagation mechanism to propagate said created generic attack signature to a controller; an external update mechanism to receive updates to said blacklist from said controller; a denial of service (DoS) module forwarding attack signature information regarding a DoS attack to said generic attack signature creating module; an anti-scan behavioral module forwarding attack signature information regarding a worm attack to said generic attack signature creating module, said generic attack signature information, after being created by the generic attack signature creation module, regarding said worm and DoS attack further including at least one of the following attributes: an accuracy level of footprint, a worm characteristic level, an attack rate, an attack direction, and a generality type; and said controller communicating with each of said plurality of said intelligent security agents over said network, said controller performs: receiving the created generic attack signatures from at least one of the plurality of intelligent security agents, matching said created generic attack signature to a plurality of propagation rules, selecting one or more of said plurality of intelligent security agents to propagate said created generic attack signature to, when the said created generic attack signature matches at least one of the plurality of propagation rules, and propagating said created generic attack signature to the selected one or more of said plurality of intelligent security agents, wherein a blacklist associated with each of the selected one or more of said plurality of intelligent security agents is dynamically updated with the at least one propagated created generic attack signature, wherein each of said plurality of propagation rules defines at least one or more of the plurality of intelligent security agents that the created generic attack signature is propagated to based in part on an intelligent security agent that created said generic attack signature and attributes of said generic attack signature, said update performed via the external update mechanism associated with each of said plurality of intelligent security agents distributed across said network.
 12. The distributed security system of claim 11, wherein a generic attack signature rule is generated from multiple footprint types with each footprint type assigned an accuracy score and based on that a generic attack signature accuracy score is set. 